Organizations, especially large enterprises (e.g., financial institutions), have been making significant, ongoing investments to keep their computer networks safe from security threats such as unauthorized access and malicious attacks. For each type of known threat, software developers usually adopt a corresponding set of countermeasures and code them into the particular web applications which need protection against that particular type of threat. Thus, each individual web application has to be modified manually to incorporate hundreds or even thousands of lines of additional code in defense against each security threat, and the resulting application software must be tested after each modification. This process apparently has to be repeated for every application whenever a new or mutated threat emerges in order to keep the protection updated.
For a large organization running a significant number of web applications on server clusters, it can become very time-consuming and costly for IT personnel to maintain and update all the applications with the proper defense mechanisms. Such conventional approach to application security is also prone to human errors and could leave security gaps in application defenses, for example, due to inconsistencies among security-related code in different applications, methods, functions, or individual lines of code.
Deficiencies also exist with respect to prior approaches with respect to specific areas of security.
Improper input validation and output encoding are also top vulnerabilities of existing web applications leading to XSS, SQL injection, command injection, resource injection, path manipulation, and so on. Although static and dynamic scan can help in identifying these vulnerabilities, having many different ways of code implementation increases risk of unidentified missing safeguards. Moreover, manual suppression of false positives in static and dynamic scan may introduce errors. Finally, it is difficult to maintain and update patterns of attack vectors if there is no central library for input validation and output encoding.
With the complexity of modern web applications, it is extremely difficult to prevent software vulnerabilities from being exploited. Even though every sizable organization and enterprise invests vast amount of resources in securing web applications, security vulnerabilities (or bugs) are still being exploited. Moreover, the fast pace at which web technologies and programming languages change makes it even harder for the defenders to catch up with the new attacks being developed by sophisticated hackers. As a result, in addition to the traditional focus on fixing software vulnerabilities via secure programming practice, attention has been shifting to detecting intrusion attempts.
While the development of intrusion detection techniques at the network layer has been the focus for many years, the battle field has been turning to the web layer but the approach adopted to detect web attacks still relies mostly on text-based pattern matching. For example, to detect a typical Cross-Site Scripting (XSS) attack, a standard set of pattern matching rules can be defined across the board to black list dangerous tags such as the case insensitive string “<Script,” as well as all HTML event attributes like “onLoad=”. However, if the application is printing tainted data from free text fields in JavaScript context, the pattern matching rules can be easily bypassed by writing JavaScript directly without using context switching control characters. Furthermore, depending on the implementation of JavaScript engines by different browser vendors, an advanced hacker is able to write malicious JavaScript using a small set of special characters only, without writing in normal JavaScript syntax. The approach is known as “obfuscation.” As web applications nowadays make heavy use of dynamic JavaScript, there are essentially unlimited ways of writing an attack vector via different encoding techniques and obfuscation, if the application is vulnerable to JavaScript injection.
On the other hand, if a very stringent set of global pattern matching rules is applied, a huge volume of false positives will be generated, which can be manipulated by the attacker to embed a true attack within a large set of false alerts in order to reduce the chance of being detected. For example, an SQL injection attack payload may look like normal English usage, and a rule written with the purpose of catching obfuscated attacks would not be appropriate for free text fields accepting English sentences and paragraphs. Moreover, if a block decision is made based upon the detection rules, the required application functionalities will be broken.
In light of the various deficiencies and problems with prior approaches, there is a need for strengthened application security, for example, by imposing particular process guidelines on security requirements, secure coding practice as well as security testing. Apart from static analysis and dynamic test, there is also a need for secure architecture design as certain issues of application security can only be addressed through a secure architecture.
Further drawings and illustrations are provided in the appendix attached hereto.